When multiple applications on a computing device share the same limited network resources on or external to the computing device, various techniques have been used to attempt to balance the networking needs of those applications. Computer users and applications usually prefer certain trade-offs and prioritizations among applications consuming network resources. However, in practice, prior techniques for sharing network access often have not optimally realized those preferences and priorities. For example, a user of a device may prefer that Voice over IP (VoIP) calls on their device have low network latency and that web browsing on the device be snappy and responsive. The user also may prefer that background bulk network transfers, such as cloud synchronizations and operating system updates, yield their consumption of the device's network resources in a way that enables satisfactory foreground performance and maintains reasonable progress.
In addition to often failing to satisfactorily share network access, prior access-sharing techniques have often not been convenient for software developers to access or implement. For example, while Quality of Service (QoS) facilities can be helpful, they are often not available or are not implemented in a uniform manner. Most QoS technology occurs below the application level and therefore may not be reliably manipulable by applications. Most QoS approaches, Differentiated Services for instance, depend on the behavior and support of the network between two endpoints. Such support may not exist on all network paths. Regarding convenience, network sharing behavior has also been implemented within applications, but this has usually required complex network programming with little or no direct coordination between applications. Not only is it duplicative for different applications to implement their own network-sharing logic, but the different resource-sharing behaviors of applications may conflict.
While there are protocols such as LEDBAT (Low Extra Delay Background Transport) that are implemented by operating systems to allow applications to implement specific types of network-consuming behavior, coding to leverage such a protocol may increase the cost and overhead of developing an application and may make a developer less likely to use such a protocol. In addition, widely deployed low-priority TCP (Transport Control Protocol) mechanisms like LEDBAT have shortcomings and often do not provide an ideal user experience (see Internet Engineering Task Force Request for Comments 6297 for other examples). The LEDBAT protocol, for instance, only restricts TCP send windows and has no effect on the receive stream, yet most client-side Internet traffic is inbound. Even when a mechanism like LEDBAT is available without requiring complex developer coding, it may not be possible for an operating system or network stack to determine that an application should use such a mechanism. In other words, user and application intent regarding network resource conflicts has been difficult to infer and applications have rarely specified their network priorities. Nor has sharing of a device's network resources been implemented in a way that is consistent among competing applications without being susceptible to problems such as the “latecomer” phenomena (e.g., see Request For Comments 6817, section 4.4).
Techniques related to implementing and leveraging classified network streams are discussed below.